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PROPAGATION OF VIRUSES THROUGH AH INFORMATION 



> h s twork ol 



ted processing entities 



virtually any processing entity (or "host") is at one 
time or another connected to one or more other hosts. Thus for example in the case of 
an IT environment, a host in the form of a compute (such as a client, a server, a 
10 rooter, or even a printer for example) is frequently connected to one or more other 

net of a commercial organisation, or as part of the 
of a communications technology e 
host k the form of a mobile telephone is, merely by virtue of its h 
going to be connected to one or more other hosts m 
IS malt k that the opportunity for the propagation q 

For e\ 5' ' e sse of a compute vims kno wn as the "Code Red" vims, c 




assimilated within a host the virus operates to generate Internet Protocol ("IP") 
addresses of other potential hosts at .random, and then instructs the host to send a copy 
of the virus to each of these randomly-generated IP addresses. Although not all. of the 
potential hosts are genuine (since the IP addresses are randomly generated), sufficient 
of the randomly generated addresses are real addresses of further hosts to enable the 
vims to self propagate rapidly through the Internet, and as a result to cause a 
substantial drop at performance of m< 
s tns t < 



more ether hosts; or a network of winch any of th 
Thus for example, a virus may act by becoming a 



enwhhin a first host, and 
30 subsequent to its assimilation may then cause deleterious effects within that first host, 
ch as c ! us may cause ad: 

ukm t $ one oi mo % further hosts at whic -j it will t s radar 

o \ tc mtivelj the vims mi > merely 

he a 
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it is propagated to one or more further hosts where it may then cause such deleterious 
effects, such as, for example, corruption and/or deletion of tiles. In yet a further 
alternative scenario, a virus may for example become assimilated within a first host, 
and then caase itself to be propag n >t hosts within t network The 

S % inn mro h w n« dt > no i i the hosts In v horn it is assimilated 

howei^rthv. \ >eofasufft ien 

magnitude to have a .negative effect on the speed of "genuine'" network traffic, so that 
th brmam f the network i erions manner The 

three examples given above are intended for ilkistration of the breadth of the term 
10 virus* and are not intended to he regarded hi any way as exclusively definitive. 

it has been ess hushed hat in situations- where viruses are likely to cause deleterious 
effects upon either one or more hosts, or the network infrastructure as a whole, one of 
die most important parameters in attempting to limit and then to reverse such effects 

IS is the speed of propagation of a virus. Human responses to events are typically one or 
more orders of magnitude slower than the px \ lU speeds of viruses and so 
snbstan 1 1 . gentry apt to arise within a network before any human 

network administrator is either aware of die problem, or capable, of doing anything to 
remedy it. Therefore any reduction in the initial rate of propagation of a vims through 

20 a network is likely to be of benefit to attempts to limit any negative effects, and/or to 
remedy them. 

* * miUr approach to tackling die problems of virus 

propagation within a network may be thought of as ax ah 1 

25 infection is prevented nslng virus-ehecking software, attempts to check all incoming 
data, for example email attachments. If subsequently a virus is discovered within a 
host, that host is typically removed from the network immediately, and disinfected 
once the nature of the virus has been established. In accordance with this philosophy 
each host may be thought of as contributing to protecting the network against 

30 widespread infection firstly by avoiding incidence of infection, and secondly in the 
event of infection, by its sacrificial removal from the network. 

The present invention provides an alternative approach to infection and propagation 
of viruses in a network of hosts. According to one aspect of the present invention, 
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conxmunieations established by one or more hosts wife other hosts within the network 
is monitored to determine whether &e or each mnniiored host is infected, and txprn 
detection of an infection, dauby which coma mm t se a eac h monitored 



5 Depending upon the precise nature of the data recorded, t may to he used to 
establish inter alia: the nature of the virus, the manner m which it propagates. 



of the it v t utmple, and v> 

to the ace? \ 




Fig Sisas* 

an application protocol from Fig. 2; 
Fig. 4 is a si 



Fig. 5 is 



ofanoperathn 



Fig.. 6 is a g 



Fig.. ? is a flowchart 



Figs. 8A and B are flowcharts : 



i i of me method of Figs. 6 
fustrating further aspects of embodiments of 
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Referring now- to Psg, 1, one typical form of network includes a plurality of client 
comparing entities 10, and a server computing entity 20 each of which is connected to 
a network backbone, usually referred to as a bus 30. in the present example, each of 
the a. n , > has a similar architecture enabling dispatch and receipt of data 

5 from other entities connected to the network. Referring now to Fig. 2, each of the 
< ni in * i.m ludt s a hat m *> b j though? o! ; s three 1 3 uris one or more 

application progmmtrcs 100, which in general terras may be thought of as enabling 

> ® fm 1 SIK Vv 

* ^ > » <ed so on; hardware 300 (such as a hard 

10 drive 310, memory 320, a processor 330, and a network card 340); and an operating 
system 200, The operating system. 200 may be thought, of, in pari, as an interface 
between the applications programmer and the hardware, and performs scheduling of 
tasks required by applications programmes, allocates memory and storage space 
amongst other things. The operating system 200 may, ia accordance with this way of 

1 5 describing the architecture of a computing entity, also include a hierarchy, or stack 
400 of programmes wim h pa>\ ide the entity in question with the ability to dispatch 
and receive data to and from other entities m the network, in accordance with a 
number of different sets of formal roles governing the transmission of data across a 
network, known as protocols. The network stack 460 may be thought of as being 

20 inserted into the operating system so that the two operate ia conjunction with each 
other. The stack 400 includes a strata of low level programmes which provide for the 
smpiementaiioB of low level protocols 404, concerned for example with the formation 
of handles of data known as "packets" {which will be discussed in mote detail later), 
the order in which bytes of data ate to be sent and, where appropriate, error defection 

25 and correction, A further, high level strata ot prcux < ted w ithin 

applications programmes ("application protocols"), apply in conjunction with the low 
level protocols to provide for the dispatch and receipt of data at the behest ot 

1 e prose it example the application programme uses four 
different high level protocols 402; RTSP (real time streaming protocol), FTP (file 

30 transfer protocol?, SMTP (simple mail transfer protocol - used for email), and HTTP 
(hyper text transfer protocol - used primarily in internet related applications), and the 
operstin s>\ i implements tw tow eve s 4oc Is 404 UDP (User Datagram 
Protocol for use with RTSP), and TCP (Transfer Control Protocol for use with the 
remaining three application protocols), both low level protocols being implemented 
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above, and in mmxmchon with Internet Protocol (IP), finally, the network stack 400 
includes a system p< nnwn as a driver 410 for iK « I, v> hieh in 

essence is low level software that controls fee network card. 



accordance with HTTP will be considered Usually a request for such a connection is 
made by the v*d> b owst ; p\ - s n to is most likely to ho 

si. fee behest of a user operating the web browser. Where th is is the case, the request 
will identify the address or 'URL** within the network of the computing entity with 
10 which a connexion is s 

xxxxits.xxx.xxx, where x is either an integer or no number at all and each set of If® 
X's is an integer no greater than 255. An example of an IP address is 192,168.2.2, 



15 The IP address is subsequently farther resolved into what is known as a physical, or 
Media Access Control ("MAC) address of the network card of the destination 
computing entity. Resolution of the URL into an IP address, and the IP address to a 
MAC address usually i 
in a manner which is » 

20 This description of the connection process in accordance with HTTP, well known per 

URL. However it should be appreciated that it is possible lor e 

ora the web browser application programme using an IP a 



than the , 1 » ters of the URL. This is an aspect of the system 

25 be haviour which has been exploited by viruses, some of which randomly generate IP 



in the context of the present application it should be appreciated that the term 
"connection" is a term of art, and is used, to refer to a manner of transmitting 
messages in which acknowledgement of receipt of data is required, so mat in the 
absence of an acknowledgement the connection is deemed either not to have been 
established or to have fai men not to have 

arrived. On application protocol winch operates using connections is HTTP, and an 
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abiishroent of a connection in accordance with HTTP will sow be 
described with reference to Figs. 2 and 3. A connection in accordance with HTTP is 
typically established at the behest of a web browser application programme (i.e. a 
programme in the applications layer 100 ia Fig, 2} within the client entity, which 



festoe 

y revests what is known as a socket 450 from the 
operating system. A socket is effectively m allocated memory space in which data 
relating to the communication sought by the web browser (in this instance) is stored 
I for a socket, the operating system dmy creates or "opens" 

which is the identifier for that particular socket. In Fig. 2 the particular socket Is 
indicated by reference numeral 450, and fee number of the socket is V s , while the 
part of the operating system which allocates the socket is shown as a 'layer" above 
IS the network stack, by which it is sought to indicate feat, from a methodical 

perspective, use of the socket (farther uses of which will subsequently be described) 
in the case of outgoing data, precedes fee passage of data &om the application 
programme to ugh the network stack. Once a socket lias been opened, the web 
browser then requests feat fee socket z is « 



a is sought, and a parameter known as fee "port" number (which is 
bcl identifying fee application protocol used), by writing these 
parameters in fee socket (which m due course will additionally contain further dais). 
The port number for connections via HTTP is usually pert 80. Once a socket has 
been created and hound the browser then requests that a connection be established, 
25 and this causes the emission of what is known as a data packet P10 to fee d 

destination port, i.e. an ideMification of fee suitable application protocol for h 
messages transmitted over the requested connection (here, because the connection is 
established m accordance with HTTP, port 80); a source port (here 3167} winch is an 
30 cabs (but one which is no* e » , at tl time, and (h) not 

already allocated as a standard number to define a port identified in accordance with 
estabiis.be si< \m ds) whose purpose is to provide, to the c 
connection, an identification of the connection in a 
since it is entirely possible that there may Simultaneously be two a 



? 



connection 5 may be used to distinguish one such 

connection from the other; a flag indicating that the ;^^naos#tsi status of the 
requeuing entity is set to "or/ 5 (messing that scqaeace numbers - which indicate the 
order of ty packet in a total nomher of packets seat - between the revesting and 
5 destination computing entity are to be synehrootsed), and m initial sequence number 
SO (this could be any number). Upon receipt of this packet the destination machine 
sends back a packet P20 identifying the source port as SO, the destination port as 
3 167, a flag indicating that the acknowledgement status is M oa n , an acknowledgement 
number 51 which augments the sequence aumber by one, and its own synchronisation 
10 flag number 200. When the requesting entity receives this packet it returns a further 
;tP30e 

i (U which augments the sequence number by one). Once this exchange is 

ties is d 
snptJ 

network stacks to the relevant application programmes indicating that a connection is 
open between them. In connection with the socket, it should also he noted that the 
socket comprises an area 460 allocated to store the actual body of the message which 
it is desired to transmit (sometimes known as the outbound message content, or the 
paylead), and similarly a fmther area 470 allocated to store the body of 




When the outgoing payioad is to be transmitted, the TCP layer breaks it up into 
packets (i.e. data structures such as those illustrated above in Fig. 3, hut further 
25 including at least part of the payioad), and the IP layer attaches an IP address header . 
Wlien as iaconnng n^SMge arrive*, it passes 




Data may alternative!) be transmitted using the protocols R i P/UDP/ii k ng 
the hierarchy of protocols in the network stack Mapmd in conjunction with each other 
to transmit the data) which do not require a connection; the dispatching entity sends a 
sty, and does not require an ackm at ot receipt. 
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Referring now to Fig. 4, when transmitting data in accordance wife B.TSP/UDF, 
media for example is streamed to a client entity 10 from a media server 20 in a series 
ofpaeketsF]Ot\M20, P120.,.,., asdtltedtsBttetwt a^owMgereceipsofmiy 
c with dos protocol typically .follows an nnturi 
r by some other 



Th«$ far all that has been ik Km to Fig \ 

it of the present invention, a layer of vital 

e VPMS acts as a gateway for all outboard data 
g entity on which it is running, and operates to a 
a of viruses within the tetwork by obsemng what is, in accordance wife a 




(also known as "hosts", since they may acts as hosts for viral infection) v 
network. In accordance with one asf>ect of the present invention, it has b 
any networks, normal network traffic (Le. j 
(! by a relatively low frequency of events m which data Is sent to 
s (i.e. hosts whieh are the intended destination for data) within the 
it have previously not been contacted. In contest, vk ally-related traffic 
a charaetetked by a relatively high frequency events k which data is 
tched (or attempts arc made to dispatch data) to previously uoeomacted 
destination hosts. Broadly speaking, the fraction of fee VPMS is to monitor 
25 abnormal and therefore possibly virally-related traffic, as defined in accordance wife a 
predetermined policy, and to record such abnormal traffic. 




e the VPMS operates upon the basis of a series of rime intervals 
or time windows, which in fee present illustrated example are of predetermined and 
30 constant length T„ in any given time window % the VPMS monitors requests to send 
data to *aev* * desl nati m hosts, i e. desfmati ; 1 liffer from 

those specified in a record of identities or ds i - m >s? recently contacted. 

The record only holds a predetermined number M ofdestkation host identities, so that 
a destination host is classified as new if it is not one of the N most recently contacted 
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destination hosts I he number ofnev n Hos ipe time % fadow - and me value 
of N are detained cm fee basis of the policy, t ypically defined by a system 
administrator, and the policy is preferably formulated to take account of the nature of 
nan vitally- related network traffic, fa this way, 4e VPMS opiates to mattes the 
5 speed at which a vims resident on the host .may propagate fern that bast to other hosts 
wuhin the network, 



gl Fig. 6A S over the course ?fa time window Tl, varien spplk ons 
% on fee workstation send requests vk the VPMS to send data 
10 (whether by connection or otherwise) to ot 

e (having multiple addressees) to a mail server, Mail {Request A) using SMTP, 



t to another user (Request B) via FTP, and the web browser 

mecfckm, {typically via a Web Proxy server), W/Server ta ore 
connect to a site using HTTP (Request €>. In the present example, outbound n 
to the VPMS from each of tbese hosts are requests to send data to m identified 





i in Fig. 7, v 
s. dA-C, a 
a of the operation of the VPMS n 
ft of individual event depicted in Figs, 6. As explained 
ith reference to a series of time intervals, or windows, 
which in the present example are of constant length. The routine is initiated at step 
"02 by as h. ? the clock which d« * h ati ag that a 

time window has commenced. At step 704 the routin - tes a dispatch record, 
d of (he nfcs c mxks rm i which rat 
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example t$ $) of destination hosts most race c lance * tin the 

policy- see later) in the previous time window are stored (ami which are shown for 
each time window m Fig. 6B). At this point the routine is effectively m a waiting 
mode until a request to send data is received at step 706, This is a step whose 
occurrence is entirely outsMe tbe control of the VPMS since it dually is initiated at. 
the behest of an application pngrantme, as is the case with Requests A, B and C. 
I ichof th v tl i notoeol layer in the 

; * ' x iheywere 
generated, to the VPMS* and this event is labelled in Fig. 7 as step 706. Step 706 may 
be thought of as a triggering event, so that when a request passes into the VPMS, the 
identity of the jested destination host specified m each the request is matched with 
the dispatch record. This matching process therefore determines whether the 



i host is a new host, andh 



$ serving to n 

•val 11 is tbe first time interval after 
start-up of the computing entity, The VPMS therefore matches the destination host 
identiti es for each o f the Requests A-C against identities held in a "default" dispatch 
record 610 for the time period Tl, which may be (and in the illustrated example, is) 

e of the 

host on which the VPMS isn 




record are those of the mail server (Request A), the file server (Request B) and the 
web proxy server (Request C). Since each of the three outbound requests from the 
workstation during the time period Tl identify a host destination snatching one of the 
three host identities in the default dispatch record, and therefore none of the Requests 

i host, the VPMS therefore takes 

> 7.10. 



Duong the course of the second time interval T2> three further outbound requests are 
30 received, identifying host destinations "intranet Peer I " (Request D), Request B 

(described above) and "Intranet Peer 2" (Request E) are received. As m the previous 
brae winder as e v\ |*MB mud le for h « request 

i.e. a step 706 as it passes through the VPMS, and is followed by the step 708 of 
matching the identity of the host destination in the request with the identities present 
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m the dispatch re. ord 61 2 for this time * »»dt * < > f in ordei to establish 

whether the request is new. The dispatch f ecoM howew is now a genuine record of 

5 Upon receipt of Request D, tfee VFMS routine for that request establishes at step 70S 
thai the identity of this host is not in the dispatch record 612, i.e. that it is a new 
destination host It therefore proceeds to step 7 1 2. where it adds a copy of the 
Request D to a virtual buffer whose contents are shown in Fig. 6C :! and then ends at 
7 .1 0. In one preferred embodiment, foe entire contents of the socket relating to 
10 Request .0 are duplicated in foe virtual buffer. However in m alternative 

Request 8, foe VFMS establishes at a step 708 that B is present in the d _ 
and so foe VPMS routine ends at step 710. Request E is also a new request within 
time window T2 and so at a step 712 the identity of host E is added to the virtual 

15 



Because receipt of requests are the trigger for foe commencement of the routine 
illustrated m Fig. 7, neither the number of occasions in a given time window in which 
foe VPMS routine is run, nor foe timing of their commencement can he koto® in 

20 advance. Additionally, as illustrated in Fig. 7, it is possihle for two (or indeed more, 
although only two are illustrated in Fig. 7) routines to he running in temporal overlap, 
since one may still be running when another is triggered by a further request. 
SimiMy, a request may trigger the execution of the routine of Fig, 7 just prior to the 
end of a time window (a situation also illustrated in Fig. 7, with steps which occur at 

25 the end of a time window/the beginning of a subsequent time window being shown in 
dashed lines), so that the execution of the routine may overlap temporally with a part 
of the next time window. The approach taken by this embodiment of foe present 
invention to this issue of overlap is relatively simple:, if at foe commencement of tune 
window T B *j, the update of foe dispatch record ior a previous time window T„ has 

30 been completed during the simultaneous running of a VPMS routine commenced m 
the previous time window T« 5 hut prior to execution foe step 712 (adding a request to 
the virtual buffer) for that murine, the sub^e mi lbs in that 

step ? 1 2 will be treated as if performed for a request received in the current time 
window!^ this I < * " § although it may on 
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> 1 eld j ioa - i s > ; 1 j rsid« oJ 

the policy simply because processing of the request received and initially processed 
do.ri.ng one time window extended into the next, time window, but this is ooi 
sigtuficanf overall. 

At the end of the time window T2 ? the virtual boiler contains two new requests, At 
this juncture (i.e. at end of time period 12), the policy which the VPMS is designed to 
monitor comes into play. In the present example, the policy provides that a single 
new host may he contacted per time interval This element of the policy is monitored 
by a fest buffer management tontine, which is iilu»? t, c, v « n flow chart 

form in Fig. 8A, and begins at step 802 with the advent of a clock timeout, that is to 
say that the clock {not shown) which defines the time intervals T* has completed 
another time period, following which, at step 803 the routine counts the number of 
requests in the virtual buffer to update the variable known as LogNo, this being the 
number of requests in the virtual buffer at any moment. At step 804 the taurine 
determines whether there are any requests in the virtual buffer, and it does this by 
examining the value of LogNo, to determine whether it's greater than 0. If there are 
no requests in the virtual buffer the routine ends at step 806. In the present illustrated 
example however it can be seen that over the course of the tune Interval T2 two 
requests, D and E have accumulated in the virtual buffer, and so the routine pmmfa 
to step 808, at which the fest request RQ1 <Le. the one which has been in the butler 
for the longest time) is deletes.! from the buffer. At step 810, the routine then searches 
the buffer for other requests specifying the same destination host and deletes any such 
requests, since they are effectively regarded as one request identity. This is followed 
he dispatch record so that it accurate!? reflects the identity of 
the three hosts most recently contac ted in accordance wi th policy. It should be noted 
that the dispatch record does not therefore necessarily reflect the identities of hosts 
which have most recently aetaaliy bem contacted, if requests to these hosts are 
outside of the policy For ex amp t host of Request E 

which aitho $ $ ted, was not contacted in accordance with the policy of one 
ne w dssiinat on host per f me inter* a* 1 h jpatc h a cord can he 

seen reflected in Fig 6B where t >e .1 sp neb record co 

U, O B The qr d sVp d it ^ 0 j the 

value o I i srzeoitoevsrt I icl i this 
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example following the tracer s * > ihe Request LK is one s x j.e the single Reqae: 5 
E). Thus, in the same way that fee diapatch record is a record of ail requests which 
have bees transmitted m accordance with policy/the virtual buffer is effectively a 
record, of all requests which have been transmitted outside that policy. 



The mle of the virtual buffer is to enable a determination to be made with regard to 
whether the host upon which the VPMS m mnmng is vimliy kfeeted. One way in 
which this can be manifested is ihe size of the virtual buffer. A state of viral infection 
may therefore be defined in terms of fee size of the buffer, and the stage of any such 
10 viral infection by the me of change of the buffer size. This follows from the 
generally diifeent behaviour of waliy-retated and mn v 
in to non vuaily-related or 'legitimate" network traffic usually involves c 
only a relatively small number of new destim 

1$ «k instance of a lar ge number of requests to c 

ivpicaihk <«eOu>a. The virtual buff< nav \ thought f ss a 

queue of virtual new requests waiting for opportunities to be virtually transmitted in 
accordance with policy {since their "countetparT real requests are simply transmitted 
without hindrance). The size of the virtual buffer is therefore one indication of 

20 whether there is viral infection, since a huge buffer size is indicative of a large 

number of requests to contact a new .host within a short space of time. An alternative 

Conversely, generally speaking a buffer size which is steadily declining from a 
relatively high value may be indicative of a temporary increase in legitimate traffic 
25 levels. It can be seen therefore that buffer size may be u 
of viral ii 

lis dotal in the policy. 




A second buffer management routine, fflusttsted m Fig. SB monitors the virtual 
30 butler, and is triggered by performance of step 814 from the routine of Fig. 8.4, i.e. an 
update in the value of the variable LogNo, following which, at decision step 842, the 
routine determines whether the size of the buffer is greater man a quantity V ls which 
the policy has determined represents viral infection, whereupon at step 844 it 
generates a vims alert. litis may simply be a visual alert to & user of the workstation 
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1 0, or a message to fee network administrator, or both, or eves a trigger for automated 
actios to sh i ed Vi step 846, th terarines 

whether fee variable V» is Increasing above a given rate, and if it is, issues a further 
warning indicating fee onset of viral infection at step S4S, following which fee routine 
ends, 

A situation in which fee second buffer to mx ates a % iral infee&n 

warning can be seen in Figs. 6A~CL As mentioned previously, during time interval 
13, a single Request A {which it will be recalled torn fee time interval If Is to 
contact the mail server), and two Requests C are received. Because fee dispatch 
record 614 for this time interval does not contain Request A, it adds the identity of 
host A to fee virtual buffer, bat not the identify of host C. At the end of fee fern 
interval T3 the virtual feoffor therefore contains Request E (stored m fee virtual buffer 
since time interval T2> and Request A, Since only one new request is fcaasmitted per 
time window in accordance with policy, and since Request E has been in fee virtual 
buffer since time interval 12, whereas Request A has just been added, Request E is 
deleted from the virtual buffer (a process wife may be thought of as 'Virtual 
transmission"), so that at fee start of time interval 14 fee virtual b uffer contains only 
Request A. This indicates that at this point in time, since startup of the entity on 
which the VPMS is running, only one .mom request has been transmitted than fee 
policy allows. The first Request for connection in time interval 74 is Request B, 
which illustrates thai over the course of three time intervals, during which only 
normal network traffic has been ununited, connection has only been requested to 
five different destination hosts. However, Request B is nonetheless defined as new 
because it's not in the dispatch record 61 6 for time interval T4, and so fee identity of 
host B is stored in the virtual buffer (this action being illustrated at the same point in 
fee t imeline in Fig. 6C}« After receipt of request B, two groups of five virtually 
simultaneous requests arc Kceived: F-J, and K-O, and since those are also new, their 
< v i ties are also &<id<^ to the virtual tefe Referring specifies]! y to Fig 6< ting 
tone interval T4, it can readily fee seen feat the virtual buffer has Increased from a size 
of one, to 12, and in accordance with fee policy, thus is defined as viral infection, 
since in the pros* nt example a buffer ske < thi a alert 

Moreover, size fee rate of change is positive and rapid (from Ho 12 in a single time 
interval) th h f s t ion fhus fee likelihood is that a 
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r of the* 



s transmitted during the course of time interval T4 



fe tne event that a vim! warning is g 
5 taken, the maj ority of which ate feefed tow; 
any possible virus. Specifciliy tteiypeof « 
the destinations to which a vims has been propagated, where applicable the 

— j3-;«heorp.rograniitjeswhkhnuscstop;< - ? at ^Xh and the 
action and behaviour of the vm The nature of the information which may obtained 
10 directly from the virtual buffer, or whtdh isay fee deduced therefrom depends ® m 



of the host c: 



em the case ofo: 



4 in the hufier, and possibly, m the case where the vims copies itself to the 
he outgoing payload, also the virus. Additionally, where the operating 
system records an identifier in the socket deaotmg fee application programme 
requesting the socket arid m ability to map this process identifier to $ 




the date in a socket is only one way in which to collect data ref«i*a| 
:iM«Ction s and when using sockets, dspoiding upon die extent of the data collected, 
the of copying of the sockets is likely to vary. For example, if, as referenced above, 
the fullest date (inclndtag e.g. copies of fee payload) is to be retained, farther copies 
of fee sockets in the virtual buffer (stored for example tn a mariner which tags them t> 
fee copy of the socket m fee virtual buffer) are preferably made over time as fee 



e in the data in a socket (e.g. fee writing of 
g data to a mc kei by an applicatio* dfi om fee 

of outgoing data by fee network stack h maintaining a complete record may 
nevertheless still be difficult simply from observing the contents of sockets. 
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In an alternative embodiment, the network stack additionally includes a layer 502, 
known ax a packet logger, known per se» According to one emhodis , whm a viral 
warning is generated as a result of the virtual buffer size {the virtual butler mis 
embodiment still being made of a single copy of a socket), the logger 502 is switched 
5 on, and makes copies of outgoing packets. These .may be all outgoing packets, or 
packed identified fey one or more particular destination IP address, the identify of 
which may for example fee established from the copies of the sockets in the virtual 
buffer. By logging packets complete information may fee stored relatively easily, 
since, for example even m the case of large payfoads, the individual packets earning 
10 various parts of die paytead may easily be aggregated using the SBQ and ACK 
ambers. Further, if desired, the use of die logger enables utcom 
may provide valuabl 
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{i.e. sends back a packet io its originating host from a destination host) as part of its 
propagation process (as is fee case, for example with d>e Nimda worm). 



The relatively early provision of waning of viral h 

I since in the ease of many viruses the rate at which they can establish 

time. For example, in the case of the code red vims, it has 
e of the first 16 hours, 10,000 hosts were infected, 
bet that in the subsequent 8 hours me wmfeeted a further 340,000 hosts. The 
early collection of data on vital infection can thus enable action to he takes, either 
within the hosts within which infection has been detected, and/or within other hosts, 
which can sub alia educe the extent > i 



a with Fig. 6, a s; 

(Request A) to &e ¥FMS S specifying a sing le destioatn 

im^mmmm&pimmtyMcmml messages to d 

y of sob-requests, here having the form of putative email 
>r dispatch from the mail server to a ! he outbound 

carrier request (similarly, the mail server may be thought of as acting as a proxy 
destination host for the ultimate addressees specified in the outbound carrier request), 
in mis situation, allowing transmission of the data packet constituting the message to 
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tvolttpie other 

hosts within the network (i.e. the specified addressees) all of which maybe sew, mm 
though, in accordance with the routine described is connection with Fig.. ?, the 
outbound earner request will only count as a single request which may not even be 
recognised as new if, as may be likely, the mail server is identified m the current 
4isp-&idi record. In such a situation therefore, if fee WMS operates simply to record 
in the virtual buffer those new destination hosts to be contacted per time window on 
the basis only of those destination hosts which are ostensibly identified is the 
©utbOsM request, the desired monitoring of viral propagation may he ehmnveuted or 
;auae a single outbound request specifying the mail server docs not 



it thus far described therefore, the WMS includes 
e a step of identifying die application programme by which m 
outbound request .has bees generated. Because certain applications programmes are 
more likely than others to use outbound carrier requests which invoke the use of a 
proxy (for example the abnveMsentiosed instance pf mm or the case of a web 
browser programme) it is possible in advance to specify criteria, based on the 



derated by one such specified a 
programme, Qm the WMS invokes the use of the application p 
reveal the identities of the destination hosts specified in the sub-requests; here the 
eventual addressees for whom the email message is intended Once the identities of 
the genuine or ultimate addressees have been obtained, there are several options for 
processing the request. In accordance with one affemativs the identities of the 

saute policy which applies to all other requests, and they can he matched against the 
host identities within the thspatch record m the manner previously described in the 



Since ia the cas e § t exa rip) c ssts to a host 

acting as a proxy for the ultimate addressees of the email messages is the norm, it is, 
iamodi& a,possi fordil i < d'VPMS i s 



IS 



effectively operating in parallel wife each other: one which applies to hosts specified 
in. the outbound request (ioci ling ess deques 8 ), and another which applies to 
hosts specified in any subtests identified by the email application, programme. In 
such a situation, each VPMS will operate uuiepeadently, using its own dispatch 
record, and ImplemeMmg s policy for outbound requests tailored to the traffic it is set 
up to oontn*, hr example to the inaMex previously described and illustrated m 
connection with Figs. 6 and X The two policies may he the same (e.g. a dispatch 
i of 3 identities, a time window of constant duration T» y aid one new host per 
ue^ub-^ue S t) >S rd1itoi 




c the VPMS 



VPMS is operating, and more particularly, the nature of the maw 
m intended to control Therefore, while a policy such as that thus 
with Figs, 6 and 7 may be effective in monitoring the propagation of v 
the network to a rate of infection of one bow host per time interval, it may also be 
susceptible to false warnings caused by nan viraJly-relatcd, or "legitimate" network 
traffic whose charaetmstic behaviour differs substantially from the policy the VPMS 
is implementing. To ameliorate this difficulty, it is possible to provide a version of 
VMPS for each application programme fxoa* which network traffic emanates, with 
each VMPS implementing a policy tailored specifically to minimise the level of 

s network traffic. Alternatively, in accordance with a farther 
i of the present in vention, an individual VPMS is provided in 
respect of each application protocol which the hosting entity supports, and r 
are routed to approjmate VPMS on the basis of the port identified in outgoing 
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CLAIMS 



1. A method of monitoring propagation of viruses within a network of hosts 
comprising the steps of: 
5 establishing a record which is at feast indicative of identities of hosts within 

the network to whom data has hem sent by a first host ("destination hosts"); 

during a first time interval, comparing (a) identities of destination hosts 
identified m quests to semi data fromihe first tert and (b) identities af destination 
hosts identified in the record; 
10 transmitting all requests to semi data; 

mot in the resold. 




4, A method according to claim 3, whereto the policy additionally defines a 
mMtmurn number of destination host identities not in the record, to whom requests 
may be legitimately transmitted m accordance with policy. 

25 

5. A method according to claim 4 further comprising the step, at the end of any 
gi ven time interval of deleting from the buffer data relating to requests transmitted 
during the given time mterva! m accordance with policy. 

30 6. A method according to claim 5 iiather comprising the step, at the end of the 
given time interval, of updating the record to reflect identities of hosts identified in 
requests which are transmitted in accordance with policy during the given time 
interval 
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7 . A method according to claim 6 further comprising the step of updating the 
record to reflect the identity of the predetermined maximum number of destination 
host identities to whom data has most recently been sent in accordance with policy. 

5 8. A method according to any one of the preceding claims, wherein the data 
stored m the buffer is a copy of a socket created to send data in accordance with a 



9. A method according to claim S wherein the socket e n 

10 least one application prograsnme at whose behest the socket k created 

1 0. A method of operating a. first host within a network of a plurality of hosts 
comprising the stepson 

over the course of a first time interval, monitoring creation of sockets within 
15 the first host to identify destination hosts identified therein; 

comparing identifies of destination hosts monitored during the first time 
intern! with destination host identifies in a record; and 

storing, in a buffer, data from ail sockets which identify destination hosts not 
in the record, 

20 

1 L A method according to claim 10 wherein the socket data stored in the buffer at 
least enables identification of the destination host identified therein. 




13. A method according to claim 5 1 w herein t e record * ? est &!& ed K 
monitoring creation of sockets during a time interval preceding the first time interval 

14. \ meih'.id aerx < therein the po 

m,o in ium numbei of socket < dying a destination host not in the record to be 
legitimately created m any gives time immd. 



2! 



IS. A method i \ , the end nten 

data containmg identities of destination hosts in respect of whom sockets have 
legitimately been created isdetetol torn the hutfe. 

5 16. A method acceding to claim 10«wr comprising the step, k fee event that 




! ?> A method according to claim 16 wherein packets having a designated 
10 destination 0> address are stored. 

IS m A method according to data 10 further comprising the step, in the event that 
the number of socket data items stored k the buffer exceeds a predetermined value, of 
storing incoming packets to the first host 




21 . A method according to claim 20, teher coming the step of establishing 
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